自動テストとGitHub Flowを組み込んだClineでの開発ワークフロー

概要

開発が反復単位に区切られて進むため，少なくとも前段階のコードレビューまでの結果は（自分の責任の程度に応じて）信頼できるという状況が作れます．

問題を見逃さないために，Commit段階とプルリクエスト段階の2回に分けてレビューを行います．

プルリクエストや複雑な作業を伴うCommitでは，作業内容をmd形式でLLM自身に書かせます．

続けて作業をする場合は作業内容の報告以降を削除することでコンテクストウィンドウを節約します．

AIエージェントの作業中，テストコード書き変えたときに特に注意を払うことで問題行動を止めやすくなります

テストコードの妥当性から先にレビューすることで，その後のソースコード本体のレビュー注意すべき箇所が絞られて楽になります．

テストコードにはLLMが指示をどのように解釈したかが明確に書かれやすいので，問題を見逃しにくくなります

ソースコードを読む前に全体を大まかに把握できてレビューしやすくなります

テスト同様にLLMの意図や実装上の問題に気づきやすくなる効果があります

? API費用が問題になります

APIの使い分け

Claude 3.7 Sonnet：短いコンテクスト（プロトタイピングや小規模な修正）

理解力が高く，状況に応じて自分で考えて行動する

用途：目的や要望のレベルの指示出しをしたい（方法を書けない，あるいは書くのが面倒な）場合

利点：漠然とした指示でも，高精度に意図を汲み取って適切に動く

欠点：困難な指示を勝手に簡略化したり，エラーメッセージなど近々の文脈に流されて元の指示を忘れたりする

その他

コンテクストウィンドウが少ないため，長期間にわたる作業には不向き

高額のため，気軽に仕事を頼めない

Gemini 2.5 Pro Preview：長いコンテクスト（保守やリファクタリング）

指示を文字通りに忠実に実行しようとする

用途：ドキュメント駆動開発に移行した大規模システムの保守や大きな改修

利点：複雑な状況や指示を与えても，それを確実に遂行するように粘り強く働く

欠点：キャッシュがなく高額．具体的な指示や文脈情報が必要．

その他

コンテクストウィンドウが大きいため，長期間にわたる作業にも対応できる

コンテクストウィンドウが大きくなると高額な費用が発生する．

Gemini 2.5 Flash：具体的な作業として指示を出せる場合

コンテクストが長く安価

用途：具体的な計画と行動レベルの指示が用意できる場合

利点：長いコンテクストを与えても安価

欠点：意図を汲まず，指示していないことはしない．また，指示の誤りも指摘せず最後まで遂行しようとする

その他

コンテクストウィンドウが大きいため，長期間にわたる作業にも対応できる

安価なため，気軽に頼みやすい

手順

1. ブランチの作成

ローカルのmain ブランチを更新（pull）

内容を簡潔に表す名前の「作業用ブランチ」を作成

「.clinerules」や「.gitignore」を現状に合わせて修正

2. Clineに指示

課題の種類に応じて以下のA~Dのいずれかに分岐

（2-A）機能追加・デバッグ

Codeに単体/結合テストを活用して機能追加/問題修正をするように指示（テストは先と後どちらがよいかは現在模索中）

テストコードを修正しているときは不正をしていないか注意深く監視

（2-B）テストのリファクタリング

Architectにテストコード全体を見て不正や問題がないかを点検するよう依頼

点検内容に応じて修正作業を実施

システムテストやE2Eテストを実施

（2-C）コード全体のリファクタリング，大規模なプログラム変更

リファクタリングの場合

Architectにコード全体の問題点を洗い出すように依頼

問題が（コンテクストウィンドウに収まる程度に）小規模な場合：

同一タスク内で修正作業を続行

問題が大規模な場合：

1. 計画をmdファイルとして書き出すように依頼

2. 最初の計画を遂行

新しいタスクを開いて計画を参照して最初のステップに取り組むように依頼≒（2-A，3，4，5に相当）

終了後に作業報告をmd形式で書き出すように依頼

リファクタリングのissueを立てて，作業計画と作業報告を適宜GitHub上にも記録

3. 最期まで計画を順番に遂行

新しいタスクを開いて，計画とこれまでの報告を参照して次のステップに取り組むように依頼

終了後に作業報告をmd形式で書き出すように依頼

issueに記録

システムテストやE2Eテストを実施

（2-D）ドキュメント刷新

現状にそぐわないドキュメントを削除

Architectに「ソースコード全体を見て熟練の開発者に引継ぎを依頼する上で必要十分なドキュメントの項目」の洗い出しを依頼

項目に基づいてドキュメントを作成・更新するように依頼

3. システムテストやE2Eテストを実施

自動テストがあるなら実行して確認

手動でもアプリケーションの動作を確認

問題があれば（2-A）に戻りデバッグ

4. git差分で作業内容を確認（コードレビュー）

Cline が行った変更をgit diffで確認

問題がある場合：

変更を巻き戻して新しいタスクを作成

2に戻り，問題を考慮しつつ再び依頼

問題はないが追加の指示をする場合：

変更をcommit

2に戻る

不明点がある場合：

作業内容の報告をmd形式でファイルに書き出してもらい，commit logやissueのコメントなどで記録する

それでも分からなければタスクの文脈内外でAskに質問する

5. ドキュメントの更新

ドキュメントが今回の追加機能やテストと整合性を持つように更新を依頼

gitの差分を確認して問題なければcommit

6. リモートリポジトリの作業ブランチにプッシュ

変更内容が問題ない場合はプッシュ

7. プルリクエスト（PR）作成

PRの下書きを Cline に依頼

GitHubの「Compare & pull request」からPRを作成

生成されたテキストの内容を確認したもの，あるいはそれを修正したものを使用

関連issueがある場合はGitHubのエディタの機能でリンク

8. レビュー，マージ，作業ブランチ削除

GitHubでの操作

PRをレビュー：CI（継続インテグレーション，Continuous Integration）などを確認

問題が無ければPRをマージ

リモートの作業ブランチを削除

ローカルリポジトリの操作

mainブランチを更新（pull）

作業ブランチを削除

9. issueの整理

作業で解決されたissueがある場合

issueをClose

Clineから今後の展望などで出されたアイデアのうち残したいものがある場合

issue形式のmdファイル作成をClineに依頼

issueを新規作成

メモ

大枠はGitHub Flowに基づく

ーーーーー

2025/4/5 19:52